Overview of SAP RFCs and BAPIs
The terms RFC and BAPI are often used
interchangeably, especially by non-SAP resources. Technically, they are
very similar but operate at two different levels of detail. Over the
course of this next section, we will further discover the similarities
and differences between these two technologies.
RFCs
RFC stands for Remote Function Call and is the
standard SAP interface when exchanging data across SAP systems or
between non-SAP systems and SAP systems. You can think of an RFC much
like a C# method, the difference being SAP provides an interface that
allows for communication with SAP systems. There are three different
types of RFCs:
|
RFC Type
|
Description
|
|---|
|
Synchronous RFC&;&;
|
As the name implies, this type of RFC utilizes request-response
connectivity when exchanging information between SAP and SAP systems or
SAP and Non-SAP systems. This is probably the most popular type of RFC
due to the popularity of Request-Response requirements.
|
|
Transactional RFC (tRFC)&;&;
|
"Transactional RFCs (tRFCs) are RFCs that are invoked as part of a
logical unit of work (LUW). On an SAP system, a LUW contains all of the
steps necessary to complete a business or programming task. A tRFC
represents a way of invoking an RFC; it is not a unique SAP artifact."
This RFC was previously known as an Asynchronous RFC
and for a good reason. Once the request is sent from a client, SAP will
process this data and associate a unique Transaction ID. This ID and
corresponding data will be stored in SAP, which allows a disconnected
client to receive the information when it comes back online. This ID is
also used when calling theRfcConfirmTransID operation, which will
confirm the tRFC call and allows SAP to remove the current entry from
its database.
tRFCs guarantee that all Logical Units of Work (LUW)&; will be
executed but cannot guarantee the order of transactions will be
maintained throughout execution. Also note, there is a performance hit
when using this method.
|
|
Queued RFC (qRFC)&;&;
|
If you need to guarantee that several transactions, either inbound or
outbound, are executed in order then qRFC provides in order, once only
delivery. Much like other ordered delivery scenarios, there is a
performance hit when using this method.
Note: qRFC client functionality has been deprecated
from BizTalk as of Microsoft BizTalk Adapter 3.0.
|
BAPIs
The simplest way to describe a Business Application
Programming Interfaces (BAPI) is a RFC-enabled function module. A
function module is a logical grouping of domain specific functions that
belong together. For instance, we may have a Human Resources (HR)
function module that will contain all available HR operations. The key
difference between BAPIs and RFCs are the levels of detail in which they
operate. You can think of BAPIs as operating a Business Process level
where as an RFC will be operating at a lower, or more granular, level.
RFCs/BAPIs vs. IDOCs
A question that comes up regularly is when to use RFCs/BAPIs versus IDOCs. It really comes down to a few factors:
Is your integration scenario synchronous or asynchronous?
Does an out-of-box interface exist?
Are you trying to chain multiple events/processes together?
Does your process require SAP Workflow?
Synchronous vs asynchronous
Synchronous scenarios are better suited to leveraging
RFCs/BAPIs due to their immediate request/response mechanisms. For
example, take the situation where SAP is the system of record for
customers within your organization, but you have chosen to use Dynamics
CRM/XRM for a specific application. We do not want to manually key in
customer information in both systems if we don't have to. So we can
build an interface that will query SAP to retrieve the master data for
an existing customer in our organization. In this situation, we would
not want to use an IDOC, if we are expecting an immediate response, as
BizTalk would send the IDOC in and then have to wait for a response from
SAP asynchronously. When SAP does send the response back to BizTalk, we
may have to correlate this response with the request that was sent into
SAP so that BizTalk can provide a correct response to the calling
application.
Conversely, if your scenario does not require an
immediate response, like a fire and forget scenario, then using an
asynchronous mode provides some additional breathing room to get a
message to SAP. In a Work Order Management (WOM) system that provides
order updates to SAP, the WOM system wants the updates to make it to
SAP, but does not need immediate feedback that the message was sent. For
instance, if our SAP system has a regular maintenance window to perform
a backup, we don't want our WOM system to be interrupted during this
planned outage. BizTalk can use its out-of-box retry mechanism to
reliably deliver this message to SAP.
Does an out-of-box interface exist?
This scenario can go either way. Not all interfaces
are created equally. For example, an IDOC may exist that allows you to
submit employee time records where as an RFC/BAPI may not and vice
versa. The ability to use an out-of-box interface and reduce, or
prevent, SAP customization is a valid situation to choose one type of
interface over another.
Are you trying to chain multiple events/processes together?
We introduced the concept of
Logical Units of Work. If you have multiple units of work that
logically tie a business process together, then using an RFC/BAPI is a
better choice due to the ability to commit and rollback transactions.
IDOCs are separate entities that are not related to each other.
Workflow
If you need to execute SAP Workflow as part of an
integrated scenario, then using IDOCs is a better alternative. You do
not want BizTalk in the middle of a Request-Response situation, with a
client, while SAP is executing workflow. This risk here is the execution
SAP Workflow can be somewhat unpredictable based upon workflow load and
priority.
